Method and system for electronic wallet access

ABSTRACT

A mobile payment system is described that facilitates efficient and secured payment transactions from an electronic wallet on a user portable electronic device with a merchant point of sale terminal over a communication link. In one aspect, a mobile device is configured for transaction operations from a plurality of mobile transaction accounts in an electronic wallet. The mobile device includes a plurality of transaction modules operable to process transaction operations with a respective mobile transaction account, each transaction module configured for transaction operations to be completed after an authentication process using a central authentication module coupled to the plurality of transaction modules, operable to verify a user input passcode and to respond to authentication requests from the plurality of transaction module after the user input passcode is verified. Preferably, at least one of the transaction modules is configured for contactless transaction operations over a contactless communication link.

FIELD OF THE INVENTION

This invention relates to a method and system for electronic walletaccess in a mobile transaction system, and more particularly toauthentication or authorization mechanisms for secure transactionoperations by a mobile device at an electronic point of sale location.

BACKGROUND OF THE INVENTION

Mobile payment account systems are generally known in which portableelectronic devices are configured to provide payment from an electronicwallet. Typically, these portable electronic devices are configured toenable a contactless communication with a merchant Point of Sale (POS)terminal to carry out a payment transaction, for example using nearfield communication (NFC) technology. As described in the Applicant'sapplications U.S. patent application Ser. No. 12/891,866, entitled“METHOD AND SYSTEM FOR ELECTRONIC WALLET ACCESS”, filed Oct. 15, 2010('866 application), U.S. patent application Ser. No. 12/905,419,entitled “MOBILE PAYMENT SYSTEM”, filed Sep. 28, 2010 ('419application), and U.S. patent application Ser. No. 12/955,373, entitled“METHOD AND SYSTEM FOR ACCOUNT MANAGEMENT AND ELECTRONIC WALLET ACCESSON A MOBILE DEVICE”, filed Nov. 29, 2010 (373 application), all of whichare incorporated herein by reference in their entirety, activated mobilepayment account data may be stored in the secure memory of the portableelectronic device which can then be used to carry out transactions withthe merchant electronic POS terminal via a NFC link.

Typically, application logic, applets, modules or the like in theportable electronic device for handling electronic wallet transactionsrequire user validation by requesting the user to first enter a correctpasscode to ensure the user really wants the transaction to be executed.This prevents “virtual pickpocketing” by the application controlling theresponse to the POS terminal only when the user has successfullyauthenticated the transaction.

As the use of mobile payment systems becomes more prevalent, paymentaccount issuers are seeking to expand the products and services that areprovided in a mobile electronic wallet. For example, an electronicwallet could be used for a plurality of different forms of transactions,such as payments, ticketing, coupons or other activities, and paymentscould be made from one of a plurality of payment accounts from the sameissuer. Each additional product or service from an issuer may requireone or more separate application logic or modules in the portableelectronic device for handling control, user verification and access tothat particular product or service over contactless transactioncommunication protocols using a respective security mechanism.Therefore, as additional products and services are added to the mobileelectronic wallet, the user is burdened with an increasingly complexsystem, particularly if each of the plurality of security mechanismsinvolves different user verification passcodes or personalidentification numbers (PIN).

What is desired is a more efficient mobile transaction system and methodwhich facilitates expedient and secured transactions from a plurality ofapplications in an electronic wallet without comprising the security ofthe system against fraudulent use of the electronic wallet.

SUMMARY OF THE INVENTION

According to one aspect of the present invention, a system is providedfor management of a plurality of application logic or modules in amobile device secure element to be controlled via a singleauthentication (or authorization) mechanism. The system facilitatessecure authentication of a user using a single controlling passcode orPIN to subsequently allow action by the plurality of application logicor modules within the issuer's control. The application logic or modulesare preferably transaction applets that interact with another device(for example, a POS terminal) over communication protocols and could beused for a variety of applications such as payment, ticketing, coupons,or other activities.

An advantage of such a system is that customers authenticate to theissuer for a variety of products and services using the same passcode asan authentication value. This allows customers to not have to remember aseparate passcode for each payment product from the same issuer, and touse the same passcode to obtain servicing of the accounts from themobile device. This single passcode is intended to apply to all itemswithin the security domain of the same issuer who is primarily liablefor the applications used. Since the issuer is responsible for ensuringthe payment credentials are validated for accessing the payment, it istheir general responsibility to ensure the entered passcode is thecustomer's correct passcode.

In another aspect of the present invention is a method of handling amobile transaction operation whereby the single controlling passcode isentered by a user to the mobile application. This passcode informationis transmitted to the central issuer authentication applet inside thesecure element for verification. The passcode is verified against localrules and counters inside an authentication applet to ensure the appletsare not locked out or otherwise unusable. A subordinate applet is thenavailable for use with a mobile transaction. Execution is then directedto the subordinate applet where it will have the PIN verified state setand the transaction will be allowed over the associated communicationinterface.

In one embodiment the authentication applet controls the passcodeverification from the subordinate applet. In an alternative embodimentthe passcode verification process has the authentication applet directlycalling the subordinate applet for simulating passcode entry to managemultiple passcodes to multiple applets. Advantageously, one controllingpasscode is used in an authentication applet to dictate usage to aseries of subordinate applets all within the ownership rights of thesecurity domain of the entire collection of applets.

The controlling passcode could be implemented using any number ofmethods including a word, phrase, numeric PIN, on-screen path gesture,or facial recognition. The passcode entered by the customer and held bythe subordinate applets could be the actual passcode entered by the useror it could optionally be mapped to a passcode held by theauthentication applet. This provides greater flexibility in the mobiledevice allowing for pass phrases or gesture based interactions andtranslating into something a subordinate applet requires such as a fourdigit PIN for instance.

In yet a further aspect of the present invention there is provided aportable device and computer program arranged to carry out the abovemethod when executed by a portable device.

BRIEF DESCRIPTION OF THE DRAWINGS

There now follows, by way of example only, a detailed description ofembodiments of the present invention, with references to the figuresidentified below.

FIG. 1 is a block diagram showing the main components of a mobiletransaction system according to an embodiment of the invention;

FIG. 2 is a block diagram showing the main hardware and/or softwareelements of a mobile device shown in FIG. 1 according to an embodiment;

FIG. 3 is a block diagram showing the main functional elements of themobile device shown in FIG. 2 according to a first embodiment of theinvention;

FIG. 4 is a flow diagram illustrating the main processing stepsperformed by the mobile device of FIG. 3 in a mobile transaction processaccording to the first embodiment;

FIG. 5 is a block diagram showing the main functional elements of themobile device shown in FIG. 2 according to a second embodiment of theinvention; and

FIG. 6 is a flow diagram illustrating the main processing stepsperformed by the mobile device of FIG. 5 in a mobile transaction processaccording to the second embodiment.

DETAILED DESCRIPTION THE INVENTION

Referring to FIG. 1, a mobile transaction system 1 according to anembodiment comprises a mobile device 3, a merchant's electronic Point ofSale (POS) terminal 5 as commonly known in the field, and an accountmanagement system 7 associated with a payment account issuer 9, all ofwhich communicate electronically with one another. The accountmanagement system 7 may provide for mobile payment account creation andactivation, transaction authorization, and other related functionality,as described in the above-referenced '866 application, '419 application,and '373 application.

The account management system 7 includes a communications server 11 anda Trusted Service Manager (TSM) server 13 for facilitating communicationbetween a middleware server 15 and the mobile device 3. The paymentaccount issuer 9 includes a payment processing (authorization and fraudmonitoring) system 9 a for authorizing and effecting paymenttransactions from payment accounts associated with the payment accountissuer 9 in response to payment transaction instructions received via apayment association network 17.

In accordance with a preferred embodiment, the mobile device 3 and theelectronic POS terminal 5 communicate with one another over acontactless communication link 19 via respective contactlesscommunication interfaces. It is appreciated that this contactlesscommunication link 19 may be a near field communication (NFC) link, aninfra-red link, an ultra-sonic link, an optical link, a radio frequency(eg. RFID) link, a wireless link such as Bluetooth or Wi-Fi based on theIEEE 802.11 standards, or any other communication link that does notrequire direct physical contact. The mobile device 3 may alsocommunicate with the account management system 7 over a cellulartelephone network 21 via a cellular network interface.

As shown in FIG. 1, the mobile device 3, that is an electronic wallet asthe term is used herein, includes a secure element 23 storing paymentaccount data (that is, electronic wallet data) 25 for one or more mobilepayment accounts that are set up on the mobile device 3. The secureelement 23 can be a Universal Integrated Circuit Card (UICC) secureelement, any other secure memory configurations such as embedded secureelement chips, or as part of a peripheral accessory device to the mobiledevice such as a micro Secure Digital card, otherwise known as a microSD card, as are known in the art. Other forms of mobile handset softwareand/or hardware can be implemented to provide built-in secure electronicwallet functionality for accessing the secure element 23, includingencryption and decryption of the payment account data 25, as necessary.The mobile device 3 can be configured with built-in functionalityproviding access to the secure element 23 on the Subscriber IdentityModule (SIM) card in the mobile device 3.

In accordance with a preferred embodiment as shown with reference toFIG. 1, payment account data 25 for a mobile payment account that issecurely stored in the mobile device 3 includes data identifying auser's account at a payment account issuer 9 from which funds can betransferred to the merchant bank 27 to complete a transaction via apayment association network 17. The payment account data 25 canadditionally include data defining an amount of pre-paid funds that havebeen transferred from the user's payment account issuer 9 to that mobilepayment account. In this way, the electronic wallet can include apayment account linked to multiple funding sources, such as a pre-paidaccount, deposit account and/or credit account. As an alternative, theelectronic wallet can include a plurality of mobile payment accounts,each linked to a respective funding source.

The mobile device 3 also includes a plurality of secure walletapplication modules 29 storing processing instructions in the secureelement 23. In accordance with a preferred embodiment of the presentinvention the processing instructions are computer-implementableinstructions. The processing instructions are used to control theoperation of the mobile device 3, to facilitate the application for andmanagement of one or more mobile payment accounts on the mobile device3, and to handle the process of conducting a transaction with a merchantvia the electronic POS terminal 5. A payment transaction with a merchantvia the electronic POS terminal 5 is facilitated using a mobile paymentaccount on the mobile device 3 to effectively transfer funds from themobile payment account on the mobile device 3, or an associated paymentaccount issuer 9, to the merchant. Other forms of transactions will beapparent to the skilled person to facilitate ticketing, coupons, andother activities.

The secure wallet application module 29 can be implemented as one ormore software components of an operating system running on the mobiledevice 3 or implemented as one or more separate software applicationsinstalled on the mobile device 3. In this embodiment, the secure walletapplication module 29 comprises an authentication module 31 forverifying or validating a user to conduct a transaction using aprovisioned mobile payment account, and a plurality of transactionmodules 33 for facilitating transactions using an activated mobilepayment account after the user has been validated. As will be describedin greater detail below, one authentication module 31 associated with asingle controlling passcode is provided to dictate usage to a series ofsubordinate transaction modules 33 that are all within the ownershiprights of the security domain for the collection of modules of aparticular issuer. The authentication and transaction modules describedherein are preferably software applications (such as applets), and canbe configured to run as background applications on the mobile device 3.The software applications monitor receipt of messages or events andactivate upon receipt of appropriate messages or events so as to carryout the above operations. The software applications can alternatively belaunched by the user. Alternatively, the secure wallet applicationmodules 29 (that is, the authentication module and transaction modules)are loaded into a virtual machine of the mobile device 3 to provide thefunctionality of the present embodiment.

A secure mobile payment account provisioning and activation process canbe carried out between the mobile device 3 and the account managementsystem 7, as described in the above referenced '866 application. Theactivated mobile payment account data stored in the secure element 23 ofthe mobile device 3 is then used to carry out payment transactions witha merchant electronic POS terminal 5 via the contactless communicationlink 19, whereby a requested amount of funds is transferred from themobile payment account stored in the mobile device 3 to the merchant'sbank 27. Techniques and protocols for implementing the authorization andtransfer of funds between the merchant POS terminal 5, the merchant bank27, and the payment account issuer 9 via the payment association network17 are well known to those skilled in the art and are therefore notdescribed further herein.

As shown in FIG. 1, the account management system 7 includes acommunications server 11, a middleware server 15, and a Trusted Servicemanager (TSM) server 13, which communicate electronically with oneanother via secure network links over a private Local Area Network(LAN), a Virtual Private Network (VPN) connection, or other dedicatedsecure connection. It is appreciated that, although the components ofthe account management system 7 in this embodiment are provided asseparate servers, one or more of the servers could be provided assoftware and/or hardware modules in the same server.

Data is communicated between the mobile device 3 and the middlewareserver 15 over the cellular telephone network 21 via a cellulartelephone network interface 35 of the communications server 11. The TSMserver 13 performs logical data preparation of the data to becommunicated to the mobile device 3 by forming appropriate commands tobe written to the secure element 23 of the mobile device 3. The preciseform of the data depends on the particular implementation of the secureelement 23 of the mobile device 3 and/or the payment association schemeprogram for facilitating payment. The TSM server 13 can also performencryption of the data, for example, of the sensitive payment accountinformation, for example, payment keys, in the mobile payment accountdata 25. The TSM server 13 then passes the encrypted data to the mobiledevice 3 via the communications server 11 and the cellular telephonenetwork 21.

In the exemplary embodiment shown in FIG. 1, the communications server11 includes a separate TSM unit 37 for establishing a trustedcommunication channel with a mobile device 3 via the cellular telephonenetwork 21, and for securely routing the data to the mobile device 3. Inthe above example, the TSM unit 37 in the communications server 11 wouldnot access any of the sensitive portions of the encrypted data that arerouted to the mobile device 3 via the cellular telephone networkinterface 35. It is appreciated that the functionality of the TSM unitmay be integrated with the cellular telephone network interface.

FIG. 2 shows the elements of the mobile device 3 according to anembodiment of the present invention. In this embodiment, the mobiledevice 3 is a mobile handset. The mobile handset operating system andhardware 41 include a user interface 43 arranged to process inputs froma keypad 45 and to control output on a display 47. As those skilled inthe art will appreciate, the keypad 45 and display 47 may be provided asseparate hardware entities of the mobile device 3 or may alternativelybe provided as an integrated entity, for example, as a touch sensitivedisplay screen user interface element as is known in the art. The mobiledevice 3 may also include components included in commonly known mobilehandsets, such as a microphone, an earpiece speaker, camera andcontroller, GPS sensors etc, which are not shown for clarity. A workingmemory 49 is provided for use by the handset operating system andhardware units 41.

Software and data may be transferred via the cellular network interface35 or via a different data communication link interface 51, for example,in the form of signals 53, which may be electronic, electromagnetic,optical, or other signals capable of being received by the datacommunication link interface 51 via a communication path 55 that carriesthe signals 53 and may be implemented using wire or cable, fiber optics,a physical phone line, a wireless link, a radio frequency link, or anyother suitable communication channel. For instance, communication path55 may be implemented using a combination of channels. As those skilledin the art will appreciate, the communication path 55 may be linked ormerged with the communication path from the cellular network interface35 to the cellular telephone network 21.

As mentioned above, the mobile device 3 includes a secure element 23.The mobile device 3 is operable to receive the payment account data 25and activation request messages from and send validation messages to theaccount management system 7 via a cellular telephone network interface35 and the cellular telephone network 21. The mobile device 3 is alsooperable to store the received payment account data 25 in the secureelement 23. The mobile device 3 is also operable to receive transactionauthorization request messages from and send authorization messages tothe merchant's POS terminal 5 via a contactless communication linkinterface 57 and the contactless communication link 19. Communicationbetween a POS terminal 5 and the mobile device 3 can involvetransmission of data in a single direction from the mobile device 3 tothe POS terminal 5, depending on an implemented protocol (such as theprotocols used by the DISCOVER ZIP™, MasterCard PayPass™, Visa Paywave™and AMEX ExpressPay™ cashless payment systems).

The mobile device 3 also includes a plurality of additional mobilepayment wallet application modules 59 which are not stored in the secureelement 23. The additional wallet application modules 59 storeprocessing instructions used to control the operation of the mobiledevice 3 to perform various mobile payment account processes using thesecure wallet application modules 29 discussed above. As shown in FIG.2, a plurality of application modules 59-1, 59-2, 59-m, 59-n, forexample, are provided for carrying out transactions with a plurality ofdifferent payment account issuers (referred to as Issuer-1, Issuer-2, .. . Issuer-n) as well as a non-issuer application module 59 m forcarrying out non-issuer related operations. Each application module 59is operable to call the secure wallet application modules 29 of thecorresponding issuer in order to complete the requested transactionafter user validation, as will be described in greater detail below. Theadditional wallet application modules 59 can also include an accountcreation sub-module and an account activation sub-module (not shown)storing processing instructions to create a request for a new mobilepayment account if desired and to carry out a secured account validationand activation processes in response to user input from the keypad 23 asdescribed in the above-referenced '866 application.

Also schematically illustrated in the exemplary embodiment of FIG. 2 arewallet security domains (SD) 61 which can be implemented in the secureelement 23 of the mobile device 3. The secure element 23 isadvantageously implemented to be compliant with one or morespecifications of a standard infrastructure in order to facilitatecommunication of data and messages between the mobile device 3 (and thesecure element 23) and other entities in the mobile payment system 1.For example, and in accordance with a preferred embodiment, the secureelement 23 is compliant with the known GlobalPlatform CardSpecifications (for example the “GlobalPlatform Card Specification 2.2”,March 2006), and accordingly includes a plurality of security domainsfor facilitating control of the management of and accessibility toexecutable operations and sensitive data associated with specific areasof the secure element 23 by the various entities in the mobile paymentsystem 1. The GlobalPlatform Card Specifications define a hierarchicalarrangement of security domains, each defining functionality and datathat can be accessed by a respective associated entity, for example,cryptographic keys or certificates, that can be used to support securechannel protocol operations between the mobile device 3 and the entityor entities associated with that particular security domain, and/or toauthorize secure element 23 content management functions.

As shown in the exemplary embodiment of FIG. 2, the secure element 23includes a wallet security domain 61 associated with one or more paymentaccount issuers and other service providers. In this embodiment, thewallet security domain 61 includes a security domain 63 associated withthe payment account issuer 9 (referred to as Issuer-1) and the securewallet application modules 29 a for Issuer-1. The secure walletapplication modules 29 a are provided as an applet package associatedwith Issuer-1, and include an authentication applet instance 31 and aplurality of transaction applet instances 33 which enable thetransaction processing functionality using an activated mobile paymentaccount. The authentication applet instance 31 and the plurality oftransaction applet instances 33 correspond to the authentication module31 and the transaction modules 33 respectively shown in FIG. 1. Thewallet security domain 61 also includes one or more other serviceprovider security domains 65 each associated with respective one or moreother wallet application modules 29 b. The wallet security domain 61also includes wallet application secure data 67 for use by the walletapplication modules 59. The payment account data 25 (not shown in FIG. 2for clarity) is also securely stored in the wallet security domain 61,for example, within the wallet application secure data 67.

The wallet security domain 61 also includes a Proximity Payment SystemEnvironment (PPSE) module 69, defining application functionalityassociated with transaction processing functionality and, in particular,for handling communications with a contactless reader of the POSterminal 5 to identify which of the one or more mobile payment accountsis to respond. The PPSE module 69 facilitates an additional applicationlayer level of control of the transaction processing functionalitybetween a respective one of the transaction applet instances 33 and thecontactless communication link interface 57. The PPSE module 69 is aprogram module inside the secure element 23 but is generally provided ina security domain associated with and controlled by the owner of thesecure element 23 and not with a specific payment account issuer 9, thusproviding for segregation that allows for privacy among issuers andmobile operators.

The wallet security domain 61 also includes a Controlling Authority (CA)security domain 71 associated with a controlling authority in the mobilepayment system 1 and a Supplementary Security Domain (SSD) code module73 associated with an intermediate security domain (not shown) to managecard content and perform cryptographic services for confidentiality.

Each security domain will be associated with one or more respectiveentities in the mobile payment system 1 depending on the particularbusiness model that is implemented by the system. The specificimplementation details of the various security domains for compliancewith, for example, the GlobalPlatform Card Specifications are outsidethe scope of this application and will be apparent to those skilled inthe art. The secure element 23 also stores a UICC applet 75 which is anapplication to manage and hold the mobile network operator'sfunctionality and secure information, such as a network key and GSM(Global Systems for Mobile Communications) PIN (Personal IdentificationNumber).

In this embodiment, a central authentication applet 31 residing in thesecure element 23 in the Issuer-1 security domain 63 is configured tocontrol verification of the passcode. The central authentication applet31 is a program that manages and verifies input of the passcode for amobile application, such as an electronic wallet, as well as managingthe passcode communication to the subordinate transaction applets 33that will control its use over the contactless communication linkinterface 57 through the PPSE module 69.

Transaction applet instances 33 also reside within the same span ofcontrol of an issuer security domain 63. The roles of the transactionapplets 33 are for implementing contactless link based transaction andactions such as payment, ticketing, coupon redemption, or other offerinteractions. These transaction applets 33 can be defined by anassociation and are licensed by the authentication applet's issuer andsecurity domain owner. The transaction applets 33 include all the logicand control to execute the associated transactions once the passcode hasbeen verified as being entered correctly by a user.

Typically, execution of each applet is controlled within a securitydomain to control scope of execution and ability to control the applet.Only those applets with the right security domain access can execute,modify or change the applet. Additionally, each applet has a finite setof exposed interfaces for interacting with the applet over specifiedchannels. Preferably, the authentication applet 31 is used as a centralpasscode manager among a series of associated subordinate appletsassociated with the same payment account issuer 9.

First Embodiment

FIG. 3 is a block diagram showing the main functional elements of themobile device 3 when configured to execute processing instructions ofthe transaction applets 33 and the authentication applet 31, accordingto a first embodiment of the invention. As will be discussed in greaterdetail below, the Issuer-1 application module 59-1 calls the securewallet application module 29 a associated with the payment accountissuer 9 to conduct a transaction process, for example, when a userwaves the mobile device 3 past the contactless communication interfaceof the POS terminal 5. As shown in more detail in FIG. 3, the Issuer-1authentication applet 31 in the secure wallet application module 29 a inthis embodiment includes a passcode verifier 77 a functional element forverifying a passcode 79 a (referred to as PIN-1) associated with all ofthe transaction applets 33 a associated with Issuer-1, and a transactionapplet interface 81 for communicating the success or failure of uservalidation by the passcode verifier 79 a to the Issuer-1 transactionapplets 33 a.

The other application modules 59 provided in the operating system 41 canbe configured to communicate with respective secure applets to conductdifferent transaction processes and functions after user validationusing different mechanisms. For example, FIG. 3 shows an example of atypical secure wallet application module 29 b associated with adifferent payment account issuer (referred to as Issuer-2) that isoptionally provided in addition to the Issuer-1 secure walletapplication module 29 a. This additional secure application module 29 bcan communicate with the Issuer-2 application module 59-2 to conducttransaction processes associated with Issuer-2. In this example, theIssuer-2 application module 29 b is not configured with a respectivecentral authentication applet and instead provides a passcode verifier77 b in the Issuer-2 transaction applet 33 b for verifying a passcode 79b (referred to as PIN-2) that is separately associated with thetransaction applet 33 b associated with Issuer-2. FIG. 3 also shows anon-issuer application module that is configured to provide electronicwallet functionality to a user that is not associated with anyparticular payment account issuer 9, for example, through a MobileNetwork Operator (MNO) secure domain applet 83 for processing andperforming functions and actions associated with the mobile networkoperator, through the cellular telephone network interface 35.

A more detailed description of the operation of these components in thisfirst embodiment will now be provided with reference to the flow diagramof FIG. 4 which illustrates a computer-implemented process for acontactless mobile transaction where the plurality of transactionapplets 33 a associated with a payment account issuer 9 uses a centralauthentication applet 31 for passcode validation. As shown in FIG. 4,the mobile transaction process begins at step S4-1 where the contactlesscommunication link interface 57 and PPSE module 69 pick up or receive asignal from the POS terminal 5 for initiating a transaction. The POSterminal 5 typically sends out a request associated with a specific typeof transaction, such as payment or ticketing. In response, at step S4-3,the contactless communication link interface 57 is instructed by themobile operating system 41 to use the PPSE module 69 to initiate atransaction. The PPSE module 69 typically stores a list of the possibleexecutable application identifiers (AID) within the secure element 23based upon categories such as payment, ticketing and the like.

The PPSE module 69 determines at step S4-5 a specific AID of atransaction applet 33 a for execution of the transaction, from thePPSE's list of AIDs, such as an AID for an application which the userhas previously selected as their default for that transaction categoryor type. The PPSE module 69 responds to the POS terminal 5 with thespecific AID. At step S4-7, the POS terminal 5 receives and optionallyverifies that the AID is within an allowed set or range for thattransaction category and proceeds to ask the mobile device 3 insubsequent interactions to execute that specific AID to complete thetransaction. Accordingly, at step S4-9, the contactless communicationlink interface 57 receives a new request message to carry out atransaction using one of transaction issuer applets 33 a as identifiedby the AID.

In this embodiment, the subordinate transaction applet 33 a performingthe transaction will call the interface 81 on the authentication applet31, at step S4-11, to verify that the correct passcode 79 a was enteredby the user. It will be appreciated that the user can authenticate tothe authentication applet 31 prior to engaging with the POS terminal 5,whereby the user selects the mobile payment account they wish to use fora transaction, enters in a passcode, and the user input passcode istransmitted to the authentication applet 31 for verification. If thepasscode verifier 77 a determines that the passcode 79 a is correct andthe authentication applet 31 is in a state where it is allowingtransactions, the authentication applet 31 will allow the nexttransaction requested by a transaction applet 33 a to proceed.Alternatively, the authentication applet 31 is configured to processvalidation of the controlling passcode (PIN-1) as required in responseto a request from the transaction applets 33 a.

Therefore, at step S4-13, the authentication applet 31 will respond witha permission to perform the requested transaction and any supportingdata for the applet to use in the transaction. At step S4-15, thesubordinate transaction applet 33 a determines from the receivedinformation if passcode authentication was successful. If theauthentication applet 31 was not able to validate the user inputpasscode, then at step S4-17, the transaction applet 33 a proceeds toblock the transaction from happening and map to a specific error code.On the other hand, if passcode authentication was successful, then atstep S4-19, the transaction applet 33 a proceeds to allow thetransaction to take place.

When processing the transaction request, the transaction applet 33 adetermines the required transaction detail information to transmit thePOS terminal 5 based upon factors such as whether the passcodeverification is in the proper state. Details of how the transactionapplets 33 a perform processing to carry out an allowed transaction arewell known to those skilled in the art and are therefore not describedfurther herein. Once the transaction is performed, the Issuer-1 walletapplet can prevent further transactions without subsequentauthentication. This also prevents “virtual pickpocketing” by ensuringonly the intended transaction is performed.

The authentication applet 31 can also process the request from thesubordinate transaction applet 33 a to ensure the request is properlymade from an allowed transaction applet 33 a, before starting theverification process. The authentication applet 31 stores the passcode79 a and an allowed number of possible user input attempts of thepasscode before blocking any transactions from proceeding before apasscode reset. If the number of incorrect entries exceeds theconfigured maximum entries before a successful passcode validation, theauthentication applet 31 will not allow any more transaction attempts.Once locked, a controlling passcode reset process is typically performedby the issuer of the authentication applet 31 through a trusted servicemanager connection into the secure element 23 where commands are sent tothe secure element 23 to reset the counter in a conventional manner.

The initial instantiation and setting of the controlling passcode is aprocess managed by the payment account issuer 9 and the issuer's TSMserver 13. The issuer's security domain 63 can be set up by the TSMserver 13 and the authentication applet 31 can be installed andinstantiated into the issuer's security domain 63. The TSM server 13 canthen send commands to make the authentication applet 31 available forexecution and initialize the passcode into an initial state along withpasscode counters.

The authentication applet 31 is configured in the issuer's securitydomain 63 so that it can limit the interfaces allowed to executecommands to a finite set of wallet applications in the mobile handsetoperating system, as well as verification requests coming from thetransaction applets 33 a.

Second Embodiment

A second alternative embodiment will now be described usingcorresponding reference numerals to those of preceding figures whereappropriate for corresponding elements. FIG. 5 is a block diagramshowing the main functional elements of the mobile device 3 whenconfigured to execute processing instructions of the transaction applets33 and the authentication applet 31. In the first embodiment describedabove, single passcode control is provided by the central authenticationapplet 31 in the issuer wallet applet 29 a controlling the passcodeverification for the subordinate transaction applets 33 a. In thisembodiment, the passcode verification process involves a passcoderequestor 87 in the subordinate transaction applet 33 a directly callingthe authentication applet 31 to retrieve an associated transactionapplet passcode for automatic passcode verification by a passcodeverifier 89 in the transaction applet 33 a. The authentication applet 31stores its known value of the transaction passcodes 85 internally in thesecure element 23 for the transaction applets 33 a to use. In this way,the security mechanism of this embodiment effectively simulates userpasscode entry to manage multiple passcodes to multiple applets.

As will be discussed in greater detail below, and in accordance withthis second embodiment, the Issuer-1 authentication applet 31 in thesecure wallet application module 29 a also provides a passcode verifier77 a functional element for verifying a passcode 79 a (referred to asPIN-1) associated with the Issuer-1 wallet applet 29 a and a transactionapplet interface 81 for communicating with the plurality of issuer-1transaction applets 33 a. The authentication applet 31 stores aplurality of Issuer-1 transaction applet passcodes 85 associated withthe Issuer-1 transaction applets 33 a (referred to as PIN-1 a to PIN-1n), in addition to the single controlling passcode 79 a as in the firstembodiment. Additionally, each of the subordinate Issuer-1 transactionapplets 33 a in this embodiment stores a respective applet passcode 91,corresponding to the transaction applet passcodes 79 a stored andcontrolled by the authentication applet 31, and requires verification ofthe transaction applet passcode 91 as part of the authenticationprocess.

FIG. 6 illustrates a computer-implemented process for a contactlessmobile transaction where the plurality of transaction applets 33 aassociated with a payment account issuer 9 perform passcode validationfor a transaction process by requesting the passcode from the centralauthentication applet 31. As shown in FIG. 6, the mobile transactionprocess begins at step S6-1 where the contactless communication linkinterface 57 and PPSE module 69 picks up or receives a signal from thePOS terminal 5 for initiating a transaction. The processing steps up toS6-9 correspond to steps S4-1 to S4-9 of the first embodiment and arenot repeated here for conciseness.

In accordance with this second embodiment, after the contactlesscommunication link interface 57 has received the new request message atstep S6-9, the subordinate transaction applet 33 a performing thetransaction will call the interface 81 on the authentication applet 31,at step S6-11, to request a passcode 79 a to complete the transaction.In response, the Issuer-1 authentication applet 31 will determine if thesingle controlling passcode (PIN-1) 79 a has been correctly entered bythe user prior to the transaction request, or proceed to request inputof the single controlling passcode by the user as described above. Ifthe passcode verifier 77 a determines that the passcode 79 a is correctand the authentication applet 31 is in a state where it is allowingtransactions, the authentication applet 31 will retrieve the transactionapplet passcode 85 a (PIN-1 a) for the requesting transaction applet 33a and proceed to communicate the retrieved transaction applet passcode85 a back to the Issuer-1 transaction applet 33 a. Alternatively, theauthentication applet 31 is configured to process user input andverification of the single controlling passcode PIN-1 using the passcodeverifier 77 a in the authentication applet 31 as required beforeresponding to the request from the transaction applets 33 a.

Therefore, at step S6-13, the authentication applet 31 will respond witha retrieved transaction applet passcode 85 and any supporting data forthe applet to use in the transaction. At step S4-15, the transactionapplet passcode 85 received the authentication applet 31 is checked bythe passcode verifier 89 in the subordinate transaction applet 33 a todetermine if it matches the stored transaction applet passcode 91. Ifthe passcodes do not match, then at step S6-17, the transaction applet33 a proceeds to block the transaction from happening and map to aspecific error code. On the other hand, if the transaction appletpasscode authentication was successful, then at step S6-19, thetransaction applet 33 a proceeds to allow the transaction to take place.

In a further alternative method, the authentication applet 31 can beused to broadcast the appropriate transaction passcode to the designatedtransaction applet for use, after validating the user using a singlecontrolling passcode. In this alternative, the user using the walletapplication would provide the authentication applet 31 with thecontrolling passcode 79 a along with which transaction applet is to beused for the subsequent transaction. The controlling passcode 79 a wouldbe verified by the passcode verifier 77 a in the authentication applet313 in the same manner as the first embodiment, but instead of waitingfor a transaction applet 33 a to ask for a transaction applet passcodefor verification, the authentication applet 31 would communicate to thetransaction applet 33 a with the appropriate transaction passcode 79 a.

The authentication applet 31 can effectively translate any transactionpasscodes 79 a necessary to the transaction applets 33 a if necessary.This can allow for the wallet application 29 a to not necessarily usethe same passcode 79 a or even restrict the single controlling passcode79 a to the same mechanisms prescribed by the transaction applets 33 a.

The transaction applets 33 a in this embodiment can keep a respectivepredefined number of allowed passcode entry attempts, as described inthe first embodiment. It will be appreciated that this should beminimally used as the authentication applet 31 is storing theappropriate transaction applet passcodes, and access control thereforelimits access to the transaction applets 33 a.

Alternative Embodiments

It will be understood that embodiments of the present invention aredescribed herein by way of example only, and that various changes andmodifications may be made without departing from the scope of theinvention.

For example, in the embodiments described above, the mobile deviceincludes a communication interface for facilitating communications overa respective type of contactless communication link. As an alternative,the mobile device may include a plurality of communication interfacesfor enabling the plurality of transaction applets to carry outcontactless communications over a plurality of respective types ofcontactless communication links. In this way, the mobile device would becapable of conducting contactless transactions over a combination ofcontactless communication links such as near field communication (NFC),infra-red and/or optical (eg. for bar code scanning), ultra-sonic, radiofrequency (eg. RFID), wireless such as Bluetooth or Wi-Fi based on theIEEE 802.11 standards, and any other communication link that does notrequire direct physical contact.

As a further embodiment, the mobile device may be additionally oralternatively configured for conducting mobile transaction operationsover any other form of communication link that requires a contact and/orcoupling of communication interfaces. In this case, the mobile devicemay include a plurality of transaction modules operable to processmobile transaction operations with a respective transaction account overa communication link via an associated communication interface of themobile device. Preferably but not essentially, at least one of thetransaction modules is configured for contactless transaction operationsover at least one type of contactless communication link.

In the embodiments described above, the mobile payment account isprovisioned on a mobile handset which communicates with the accountmanagement system via a cellular telephone network. Instead of a mobilehandset, other portable electronic devices configured for contactlesspayment with a merchant electronic POS, and having suitable input anddisplay means, may carry out the functionality of authenticating atransaction using a central authentication module, as described in theabove embodiment. Additionally, the portable electronic device isconfigured to communicate with the account activation system via anyother form of communication channel instead of or in addition to theabove discussed over the air channels, such as a wired or wirelessnetwork connection, a Bluetooth connection, or the like. Alternatively,the mobile payment account data is provisioned on the portableelectronic device by data transfer via any suitable data communicationpath or by way of a computer readable medium.

In the embodiments described above, the mobile device stores a pluralityof application modules (also referred to as computer programs orsoftware) in memory, which when executed enable the mobile device toimplement embodiments of the present invention as discussed herein. Thesoftware is stored in a computer program product and loaded into themobile device using any known instrument, such as removable storage diskor drive, hard disk drive, or communication interface, to provide someexamples.

In the embodiments described above, the account management system isdescribed as a separate entity to the payment account issuer and theassociated payment processing system. The account management system canbe provided as an integral part or sub-system of the payment accountissuer and/or payment processing system.

In the embodiments described above, the passcodes are personalidentification numbers (PINs). Alternatively or additionally, the walletapplication could use any other form of passcode such as an alphanumericpasscode, a numeric passcode of varying length, gesture based actions,or facial recognition.

Alternative embodiments may be envisaged, which nevertheless fall withinthe spirit and scope of the following claims.

The invention claimed is:
 1. A mobile device configured as an electronicwallet for transaction operations from a plurality of mobile transactionaccounts, the mobile device comprising memory, the memory comprising asecure wallet application module having: a first module, anauthentication module, and a plurality of transaction modules, eachtransaction module associated with a different transaction type, thefirst module having programmed instructions to: receive a transactionrequest from a terminal device, the transaction request associated witha first transaction type of a transaction; identify a first transactionmodule of the plurality of transaction modules that is associated withthe first transaction type; and transmit a signal to the firsttransaction module indicating the transaction; wherein theauthentication module is in communication with the plurality oftransaction modules, the authentication module having programmedinstructions to: receive a controlling passcode from a particular issuerof a plurality of issuers; store the controlling passcode in the memoryof the mobile device; receive an authentication request from the firsttransaction module; receive a user input passcode; verify the receiveduser input passcode on the mobile device by comparing the user inputpasscode to the stored controlling passcode; responsive to verifying thecontrolling passcode, retrieve a first unique transaction passcode froma database of the authentication module, the database stored in thememory; generate a response to the received authentication request afterthe controlling passcode is verified, wherein the response includes thefirst unique transaction passcode; and transmit the generated responseto the first transaction module; and wherein the plurality oftransaction modules are associated with the particular issuer of theplurality of issuers, and wherein each transaction module of theplurality of transaction modules is associated with a unique transactionpasscode of a plurality of transaction passcodes associated with theparticular issuer, the first transaction module of the plurality oftransaction modules having programmed instructions to: responsive toreceiving the signal indicating the transaction, generate theauthentication request, wherein the authentication request includes arequest for the first unique transaction passcode associated with thefirst transaction module; transmit the authentication request includingthe request for the first unique transaction passcode to theauthentication module of the secure wallet application module; receive aresponse to the authentication request, wherein the response to theauthentication request includes the first unique transaction passcode;verify the first unique transaction passcode on the mobile device bycomparing the first unique transaction passcode to a transactionpasscode stored within the memory; and process a transaction operationfor the transaction only after verifying the first unique transactionpasscode.
 2. The mobile device of claim 1, wherein each of the pluralityof transaction modules performs an authentication process comprisingtransmitting to the authentication module a request for confirmationthat the plurality of transaction modules can allow the transactionoperations to be completed.
 3. The mobile device of claim 1, wherein theauthentication module transmits the generated response including thefirst unique transaction passcode to the first transaction module inresponse to receiving the authentication request.
 4. The mobile deviceof claim 1, wherein the authentication module broadcasts the generatedresponse including the first unique transaction passcode to the firsttransaction module in response to receiving an indication of the firsttransaction module from a user associated with the user input passcode.5. The mobile device of claim 1, wherein the authentication modulestores the plurality of transaction passcodes associated with theplurality of transaction modules.
 6. The mobile device of claim 5,wherein the authentication module maps the user input passcode to astored first unique transaction passcode.
 7. The mobile device of claim5, wherein the plurality of transaction passcodes associated with theplurality of transaction modules are the same as the user inputpasscode.
 8. The mobile device of claim 1, further comprising at leastone other security domain associated with a different payment accountissuer, and at least one other transaction module associated with adifferent payment account issuer and provided in said at least one othersecurity domain.
 9. The mobile device of claim 1, wherein each of theplurality of transaction modules comprises computer-implementableinstructions for processing transaction operations with a paymentaccount issuer using a communication protocol.
 10. The mobile device ofclaim 1, wherein at least one of the plurality of transaction modules isconfigured to process a contactless transaction operation with a paymentaccount issuer using a contactless communication protocol.
 11. Themobile device of claim 1, wherein the transaction operations comprise apayment transaction, a ticketing transaction and a coupon transaction.12. The mobile device of claim 1, wherein the controlling passcodecomprises numeric, alphabetic, alphanumeric or non-alphanumeric symbols.13. The mobile device of claim 1, wherein the authentication modulefurther comprises a counter operable to maintain a count of user inputattempts for passcode verification, wherein the authentication module isoperable to communicate failure of the passcode verification when thecount exceeds a predefined number of attempts.
 14. The mobile device ofclaim 1, further comprising a non-issuer application module operable toprocess non-issuer related operations associated with the electronicwallet wherein the non-issuer application module is configured to allowan operation to be completed after an authentication process using theauthentication module.
 15. A system comprising an account managementsystem coupled to at least one payment account issuer, the accountmanagement system comprising: a database storing data associated with aplurality of mobile transaction accounts; and a middleware serverstoring computer-implementable instructions to configure a mobile devicecomprising memory for transaction operations from the mobile transactionaccounts, the middleware server comprising: computer-implementableinstructions to provide an authentication module and a plurality oftransaction modules to the mobile device, each of the plurality oftransaction modules associated with a different transaction type and incommunication with a first module, wherein the first module is operableto: receive a transaction request from a terminal device, thetransaction request associated with a first transaction type of atransaction; identify a first transaction module of the plurality oftransaction modules that is associated with the first transaction type;and transmit a signal to the first transaction module indicating thetransaction; the authentication module being coupled to the plurality oftransaction modules, the authentication module operable to: receive acontrolling passcode from a particular issuer of a plurality of issuers;store the controlling passcode in the memory of the mobile device;receive an authentication request from the first transaction module;receive a user input passcode; verify, in response to the receivedauthentication request, the received user input passcode on the mobiledevice by comparing the user input passcode to the stored controllingpasscode; responsive to verifying the controlling passcode, retrieve afirst unique transaction passcode from a database of the authenticationmodule, the database stored within the memory; generate a response tothe received authentication request after the controlling passcode isverified, wherein the response includes the first unique transactionpasscode; and transmit the generated response to the first transactionmodule; wherein the plurality of transaction modules are associated withthe particular issuer of the plurality of issuers, wherein eachtransaction module of the plurality of transaction modules is associatedwith a unique transaction passcode of a plurality of transactionpasscodes associated with the particular issuer; andcomputer-implementable instructions to provide the first transactionmodule of the plurality of transaction modules having an authenticationmechanism to: responsive to receiving the signal indicating thetransaction, generate an authentication request, wherein theauthentication request includes a request for a first unique transactionpasscode associated with the first transaction module; transmit theauthentication request including the request for the first uniquetransaction passcode to the authentication module of the secure walletapplication module; receive the response to the authentication request,wherein the response to the authentication request includes the firstunique transaction passcode; verify the first unique transactionpasscode on the mobile device by comparing the first unique transactionpasscode to a transaction passcode stored within the memory; and processa transaction operation for the transaction only after verifying thefirst unique transaction passcode.
 16. In a mobile device comprisingmemory, the memory comprising a secure wallet application module havinga first module, an authentication module, and a plurality of transactionmodules associated with a particular issuer of a plurality of issuers,each transaction module associated with a different transaction type, amethod of processing transaction operations from a plurality of mobiletransaction accounts in the secure wallet application module,comprising: using the first module: receive a transaction request from aterminal device, the transaction request identifying a first transactiontype of a transaction; identify a first transaction module of theplurality of transaction modules that is associated with the firsttransaction type; and transmit a signal to the first transaction moduleindicating the transaction; using the plurality of transaction modules,wherein each transaction module of the plurality of transaction modulesis associated with a unique transaction passcode of a plurality oftransaction passcodes associated with the particular issuer and thefirst transaction module of the plurality of transaction modules havingprogrammed instructions to: responsive to receiving a signal indicatingthe transaction, generate an authentication request, wherein theauthentication request includes a request for a first unique transactionpasscode associated with the first transaction module; transmit theauthentication request including the request for the first uniquetransaction passcode to an authentication module of the secure walletapplication module; receive a response to the authentication request,wherein the response to the authentication request includes the firstunique transaction passcode; verify the first unique transactionpasscode on the mobile device by comparing the first unique transactionpasscode to a transaction passcode stored within the memory; and processa transaction operation for the transaction only after verifying thefirst unique transaction passcode; and using the authentication modulecoupled to the plurality of transaction modules, the authenticationmodule having programmed instructions to: receive a controlling passcodefrom a particular issuer of a plurality of issuers; store thecontrolling passcode in the memory of the mobile device; receive theauthentication request from the first transaction module; receive a userinput passcode; verify the received user input passcode on the mobiledevice by comparing the user input passcode to the stored controllingpasscode; responsive to verifying the controlling passcode, retrieve thefirst unique transaction passcode from a database of the authenticationmodule, the database stored within the memory; generate the response tothe received authentication request after the controlling passcode isverified, wherein the response includes the first unique transactionpasscode; and transmit the generated response to the first transactionmodule.
 17. The mobile device of claim 1, wherein the mobile device isin communication with the terminal device via a near-field communicationlink, the authentication module having further programmed instructionsto: receive the transaction request via the near-field communicationlink; and responsive to processing the transaction operation,transmitting, via the near-field communication link, an indication thatthe transaction operation was processed to the terminal device.